home *** CD-ROM | disk | FTP | other *** search
/ BCI NET / BCI NET Dec 94.iso / archives / utilities / packers / packdev1.1.lha / PackDev.doc < prev   
Text File  |  1994-08-18  |  14KB  |  378 lines
  1. Program(s):         PackDev V1.1
  2. Author:             Christian Wasner
  3. Date:               18-Aug-94
  4.  
  5. o) Version
  6.  
  7. $VER: PackDev.doc V1.1 (18-Aug-94)
  8.  
  9. i) Disclaimer
  10.  
  11. The  author  cannot  be held liable for the suitability or accuracy of this
  12. manual  and/or  the  program(s)  it  describes.   Any  damage  directly  or
  13. indirectly caused by the use or misuse of this manual and/or the program it
  14. describes is the sole responsibility of the user her/him self.
  15.  
  16.  
  17. ii) Copyright/Distribution
  18.  
  19. All  files  mentioned in iii) are (c) Copyright 1994 Christian Wasner.  All
  20. rights reserved.
  21.  
  22. These  programs  are  FREEWARE, so no financial donations are required (but
  23. welcome).   They  may  be  freely  distributed  as long as all files remain
  24. unchanged and are included with the distribution.  Distribution on disks or
  25. CDs is permitted only on the disks or CDs from Fred Fish or the Aminet CDs.
  26. Electronical  distibution  (e.g.  by Aminet, mailboxes, modems) is allowed.
  27. Packing is only allowed with LhA.
  28.  
  29. Advertisement  (especially  BBS ads) is tolerated as long as the total size
  30. of  these  is less than 20KB.  Also no profit is to be made by selling this
  31. program.  The price must not exceed the costs of disk, package and mailing,
  32. i.e. $5 per disk or $40 per CD.
  33.  
  34.  
  35. iii) Files
  36.  
  37. The following files should come along:
  38.  
  39. PackDev      (16184 bytes)
  40. PackDev.doc  (13850 bytes)
  41.  
  42.  
  43. iv) Documentation
  44.  
  45. Program:       PackDev
  46.  
  47. Template:      ACTION/A,FS=FILESYS/K/O,F=FILE/K/O,P=PACK/K/O,M=MEMTYPE/K/O,
  48.                XB=XPKBUFSIZE/K/N/O,CU=CLRUNUSED/S/O,ETDF=ETDFORMAT/S/O,
  49.                TDF=TDFORMAT/S/O
  50.  
  51. Purpose:       Reading/writing data directly to filesystems with xpk support.
  52.  
  53. Specification:
  54.  
  55. With  this program you can read or write data directly from/to a disk.  The
  56. blocks  of  the  disk are read and stored into a file.  When reading from a
  57. DOS  disk, only the blocks that are used are archived.  When writing a file
  58. from  a  DOS disk to a disk, only the blocks are written that are stored in
  59. the  archive.   Optionally  the data read from a disk can be packed with an
  60. xpk packer.  The program currently only has a shell interface.
  61. All  this  sounds like "Oh no, yet another DMS clone", but this program can
  62. handle  any device with a filesystem (e.g.  DHx:, CDx:, a RAD:  of any size
  63. etc.),  DMS can only handle floppy disks or devices with the size of floppy
  64. disks.   Even  Non-DOS disks can be handled (but then all blocks are read).
  65. Another  advantage  of  PackDev is that is doesn't use stolen code like the
  66. authors of DMS do (see below).  PackDev supports the xpk packer system thus
  67. it's  much  more  flexible  than DMS.  You can use any xpk packer you like,
  68. e.g.  a disk with pictures or sounds or <insert here> can be packed with an
  69. xpk  packer  suited  for  pictures  or sounds or <insert here again>.  When
  70. comparing  size,  you see that DevPack is only 16 KB long !  If you pack it
  71. with PowerPacker, it would be less than 10 KB !
  72.  
  73. A disk is read as follows:
  74.  
  75.    1. Read device data from DOS
  76.    2. Check  if  the  file  system of the disk is supported (currently OFS,
  77.       FFS,  OFS  International,  FFS International, OFS Directory Dache and
  78.       FFS Directory Cache are supported)
  79.     3. Inhibit device
  80.    
  81.    If filesystem is supported:
  82.  
  83.    4. Read root block (contains location of block allocation map = BAM)
  84.    5. Read BAM and store it (after packing, if specified)
  85.    5. Read used blocks and store them (after packing, if specified)
  86.    6. Quit
  87.  
  88.    If file system is not supported
  89.  
  90.    4. Read all blocks and store them (after packing, if specified)
  91.    5. Quit
  92.  
  93. Writing functions similarly.
  94.  
  95. When  writing to a filesystem, DevPack will only allow filesystems that are
  96. exactly  of  the  same  partition  size,  block size and number of reserved
  97. blocks.   If the disk should be formatted, the track size of the disk (e.g.
  98. 11 blocks for a floppy disk) must currently be equal, too.
  99.  
  100. The  program can be aborted at any time with CTRL-C.  When doing this while
  101. data is processed, you have to confirm this.
  102.  
  103. The following parameters are supported:
  104.  
  105. ACTION
  106. ======
  107.  
  108. This parameter must be specified. The following types of action are possible:
  109.  
  110. READ        - Read from a disk into a file
  111. WRITE       - Write from a file onto a disk
  112. VIEWFILE    - View a file
  113. VIEWFILESYS - View various disk parameters
  114.  
  115.  
  116. FILESYS (or FS)
  117. ===============
  118.  
  119. This  parameter  must be specified along with a DOS device name if and only
  120. if  ACTION  is  not  set  to  VIEWFILE  It specifies the disk that is to be
  121. handled  (with  ":")  etc.  Note that
  122. copy-protected disks cannot be handled.
  123.  
  124. Examples:
  125.  
  126. FS DH0:
  127. FS RAD:
  128. FS CD0:
  129.  
  130. FILE (or F)
  131. ===========
  132.  
  133. This  parameter  must  be  specified  along  with a filename if and only if
  134. ACTION  is  not  set  to  VIEWFILESYS.  It specifies the file that is to be
  135. handled.   If  used when writing to the file, a suffix ".pkd" will be added
  136. to the file name if it's not present.  If used when reading from it and the
  137. file name doesn't contain the ".pkd" suffix, it's checked first if there is
  138. a  file <name>.pkd.  If this file doesn't exist then the original file name
  139. is used.
  140.  
  141. Example:
  142.  
  143. F boo.bar     (will be extended to foo.bar.pkd)
  144. F foobar.pkd  (will not be extended)
  145.  
  146. PACK (or P)
  147. ===========
  148.  
  149. This  parameter  is  optional,  but  strongly  suggested.   It  may only be
  150. specified  along  with  a  READ action.  When writing to a disk, the packer
  151. type  of the file is automatically recognized.  Along with it an xpk packer
  152. name  and  the  efficiency can be specified (separated by a ".").  The best
  153. xpk  packers  for  standard data are NUKE and SHRI.  NUKE is less efficient
  154. than  SHRI,  but much faster than SHRI.  NUKE is 10-20% less efficient than
  155. the DMS packing algorithm, but faster.  When unpacking, NUKE is much faster
  156. than  DMS  or SHRI.  SHRI is 10-20% better than DMS, but slower.  A general
  157. rule  is  :The  less  full  a disk is, the slower is DMS because DMS always
  158. reads  all  blocks, even if they are not put into the archive (maybe ParCon
  159. is afraid of "lamers" who think, DMS forgets to read them :-).
  160.   Note that some packer types ignore the efficience value.
  161.  
  162. Examples:
  163.  
  164. P NUKE.100   (Use NUKE packer with efficiency 100)
  165. P SHRI.75    (Use SHRI packer with efficience 75)
  166.  
  167. MEMTYPE (or M)
  168. ==============
  169.  
  170. This  parameter is optional.  It specifies the memory type that is used for
  171. device  buffers.   Some  older  devices  may  require chip memory for their
  172. buffers.   For  example,  under  1.3  the  trackdisk.device  needed chipmem
  173. because  it  used  the blitter to decode the data (not because the disk DMA
  174. functions  with chipmem only).  Possible values are CHIP, FAST, ANY.  Under
  175. 2.0+ trackdisk doesn't need chipmem any longer.
  176.  
  177. Examples:
  178.  
  179. M CHIP (chipmem will be used or program fails)
  180. M FAST (fastmem will be used or program fails)
  181. M ANY  (default: highest-priority memory will be used)
  182.  
  183. XPKBUFSIZE (or XB)
  184. ==================
  185.  
  186. This  parameter  is  optional  and  can only be specified along with a READ
  187. action  along  with  an  xpk  packer.   It specifies the size of the memory
  188. blocks  in  device  blocks that are packed.  Default is 65536 bytes.  Since
  189. some  packers need a certain minimum memory block size and some packers are
  190. more efficient with a larger size, this parameter is implemented.
  191.  
  192.  
  193. Examples:
  194.  
  195. XB 200   (xpk memory block set to 200 blocks, normally 100KB)
  196. XB 50   (xpk memory block set to 50 blocks, normally 25KB)
  197.  
  198. CLRUNUSED (or CU)
  199. =================
  200.  
  201. This  optional  parameter  is allowed only when writing to a disk.  If set,
  202. all  unused  blocks are overwritten with zeroes.  This has the disadvantage
  203. that  the  write operation becomes slower, but has the advantage that tools
  204. like  DiskSalv ((C) by Dave Haynie) don't find all these old file fragments
  205. when  trying  to undelete an accidentally deleted file (deleted after usage
  206. of PackDev, of course). Default is "CU not set".
  207.  
  208. Example:
  209.  
  210. CU     (PackDev overwrites unused tracks with zeroes)
  211.  
  212. ETDFORMAT (or ETDF)
  213. ===================
  214.  
  215. This  parameter  is  optional.  It should be set if you want to write to an
  216. unformatted  floppy disk.  It may not function if you write to a hard disk,
  217. since  this parameter causes PackDev to use a format routine that functions
  218. with  floppy  disks  (DFx:)  but  may not function with other devices (like
  219. oktagon.device,  my  hd  device,  it  took  hours  to  find this out).  The
  220. advantage  of this format routine is that label buffers can be written with
  221. it  (the place where filenotes are written into) in one row.  TDFORMAT will
  222. start an extra run for the label buffers (see below).  Try it out with your
  223. hd.  For programmers:  This causes PackDev to format with ETD_FORMAT.
  224.  
  225. Example
  226.  
  227. ETDF  (enhanced format routine for floppies activated)
  228.  
  229. TDFORMAT (or TDF)
  230. =================
  231.  
  232. This  parameter  is optional.  It should not be set if you want to write to
  233. an  unformatted floppy disk.  It will function if you write to a hard disk,
  234. since  this parameter causes PackDev to use the general format routine that
  235. should  function  with  any  disk  device  that  is supported by DOS.  This
  236. general  format  routine  (TD_FORMAT,  to  be  specific) is slower than the
  237. format  routine  stated  above,  because it needs an extra run to write the
  238. label buffers (don't ask my why I don't know).  I don't suggest to use this
  239. parameter for hard disks because they don't need to be Amiga-formatted.  It
  240. is  implemented  because  there may exist some devices that need formatting
  241. but don't support the enhanced routine.
  242.  
  243. Example
  244.  
  245. TDF  (standard format routine activated)
  246.  
  247.  
  248.  
  249. Examples for usage:
  250.  
  251. Reading  the  disk in DF0:  and storing the data into RAM:disk.pkd, packing
  252. it with the SHRI algorithm:
  253.  
  254. PackDev READ FS DF0: F RAM:disk P SHRI.100
  255.  
  256.  
  257. Writing the data (eventually packed) from DH0:DH1.pkd to DH1
  258.  
  259. PackDev WRITE FS DH1: F DH0:dh1
  260.  
  261.  
  262. Writing data to an unformatted floppy disk
  263.  
  264. PackDev WRITE FS DF1: F DH0:disk ETDF
  265.  
  266.  
  267. Checking the header of a .pkd file
  268.  
  269. PackDev VIEWFILE F ram:abc
  270.  
  271.  
  272. Checking the dimensions and parameters of DH0:
  273.  
  274. PackDev VIEWFILESYS FS DH0:
  275.  
  276.  
  277. v) Compatibility
  278.  
  279. This  program  needs OS V2.0+ to run.  If you want to use xpk packers (very
  280. likely),  you  need  the  xpkmaster.library and some packer sublibraries (I
  281. suggest  xpkSHRI.library  and  xpkNUKE.library).   The xpk package and some
  282. more  sublibraries  should  be  present  in  any good pd mailbox and in the
  283. Aminet.   It is not included here because it's much larger than the PackDev
  284. package
  285.  
  286.  
  287. vi) Bugs
  288.  
  289. If  the  disk  should  be  formatted,  the track size of the disk (e.g.  11
  290. blocks  for a floppy disk) must currently be equal to the track size of the
  291. disk  from  which  the file is read.  This is not necessary, but coding the
  292. thing  this way is easier and faster.  This is not really a bug, its better
  293. called a misfeature.
  294.  
  295. If  a  pc-formatted  disk  should  be  read and no disk is present, PackDev
  296. doesn't  recognize this before the exec device is opened, i.e.  the message
  297. "device  error  at  block <mid-of-device block>" appears instead of "Please
  298. insert  disk".   This  is  not  my  fault,  because the CrossDos filesystem
  299. doesn't recognize if there is a disk in the drive.  This will not be fixed,
  300. I   don't  want  to  write  special  code  for  each  filesystem  that  has
  301. misfeatures.
  302.  
  303. Should you detect a bug, please tell me (email or phone). Be as specific as
  304. you can.
  305.  
  306.  
  307. vii) Future
  308.  
  309. What may be done in the future:
  310.  
  311. GUI
  312.  
  313. Device that treats an archive like a disk
  314.  
  315. Built-in packer
  316.  
  317. What will not be done in the future:
  318.  
  319. DMS compatibility (see below)
  320.  
  321. Localization  (I  hate those zillions of useless files, there is no support
  322. for  people  who  cannot speak English.  This sounds arrogant, but I think,
  323. this tool should not be used by inexperienced users anyway)
  324.  
  325. Versions  for each type of processor (I made the experience that doing this
  326. causes  a  negligible  speedup  that  is  not  worth even writing this, but
  327. perhaps there will be a C compiler that can do better...)
  328.  
  329.  
  330. viii) my personal opinion
  331.  
  332. Note that PackDev will never support the DMS packing algorithm, because the
  333. current  authors  of  DMS  (ParCon)  use  stolen code from the original DMS
  334. (which  was  written from someone else who has not given up his copyrights)
  335. and  release  DMS  as shareware.  In my opinion, they are not allowed to do
  336. so.   It's  not  enough to assume that you can do with copyrighted material
  337. what  you want, only because you cannot contact the real authors.  It would
  338. be  OK  to  release DMS in the public domain, but making money with someone
  339. else's  code  is called FRAUD and THEFT.  It's worse than piracy - shame on
  340. you,  ParCon  !!!   Note  that  you may own pirate software if you bought a
  341. "registered"  version  of  DMS  that  has  a version greater than 1.11.  An
  342. interesting consequence:  It may not matter if you use a cracked version of
  343. DMS  or  a "registered" version.  If ParCon doesn't have the copyrights for
  344. DMS, they cannot sue for cracking it.  I've seen mailboxes that put cracked
  345. versions of DMS into their PD area for this reason.
  346.  
  347.  
  348. ix) History
  349.  
  350. V1.0: 14-Aug-94 (released)
  351.  
  352.  - Initial release, no bugs known
  353.  
  354. V1.1: 18-Aug-94 (not released)
  355.  
  356.  - Check for known filesystems now bulletproof
  357.  - If no disk is present when starting, it will be requested for
  358.  - Minor doc editing
  359.  
  360. x) Address
  361.  
  362. I  will not give my address to the public because of bad experiences I have
  363. heard  of  (getting  into  computers  of address dealers, being blackmailed
  364. etc.).   Use  phone  or  email (the latter is preferred).  Persons I know a
  365. little can get my address, of course.
  366.  
  367. Christian Wasner
  368.  
  369. Phone - from out of Germany: <number for Germany>40/7236349
  370.       - from within Germany: 040/7236349
  371.  
  372. Email: wasner@ifm.uni-hamburg.de
  373.        crisi@dame.zer.sub.org
  374.  
  375. If  possible, use email.  If you phone me, please do it from 7pm to 9pm and
  376. don't  forget  that we have Mean European Time here, so 8pm for you may not
  377. mean 8pm for me !
  378.